A trace monitor helps embedded software developers to debug software that has been written for a system on chip (SoC). A SoC is an integrated circuit that incorporates typical computer components, such as central processing units (CPUs), graphic processing units (GPUs) and memory controllers in a single silicon die. These components communicate with each other over on-chip interconnects. For embedded software developers, it might be helpful to observe the software-caused communications as they propagate through the interconnects. This may provide information, such as transferred data words between CPU and memory, which can be used for debugging.
The process of capturing signal values for later observation is called tracing and the captured data is called the trace-data. The entity performing the observations is usually described as a trace monitor. Depending on the type of interconnects, trace monitors may hook up to either a bus or to one or more ports of a crossbar switch.
A trace monitor should never become an active member of the interconnects. It should always stay invisible for other components in order to comply with the paradigm of non-intrusive tracing. In a multitude of scenarios, the interplay of the different parties on the bus may be the cause of a bug. To take a single example, two components may be engaged in a race condition, because both want to interact with the same memory location at the same time. Altering these race conditions, e.g. due to a trace monitor that utilizes the same bus to transmit its trace data, may cause the bug to disappear.
Generally, SoC protocols are distinguishable from one another by vendor and their intended use-case and performance. Some of the most sophisticated and widespread interconnect protocols are: the ARM AMBA (Advanced Microcontroller Bus Architecture) protocol family; the IBM Core Connect protocol family; and the Open Core Protocol (OCP).
Many solutions employ IDLE cycle filtering as a trace-size reduction technique. If a trace solution offers advanced trace-size reduction techniques, such as signal compression and abstraction, it is only available for the AHB protocol. Unfortunately, AHB is considered only a mid-performance protocol, which disqualifies these solutions for use in high-performance SoCs that use faster protocols. On the other hand, if a solution supports high-performance protocols, it offers only IDLE cycle filtering and no further, advanced trace-size reduction techniques.
Therefore, it would be advantageous to have a method, system, and computer program product that addresses one or more of the issues discussed above.